The approach you've taken here is interesting.

Unfortunately, it will only work if the RPC provider returns the correct access list. We don't want to trust the RPC provider and so we can't really trust that they will provide a correct access list. They could for example provide you with an access list that will cause the eth_call result to be completely different, even though you are verifying the account and storage proofs of each account and slot there is no way to verify that you are looking up the correct pre-state before the transaction is executed.

I think using the access list purely as a performance optimization would be ok as long as the EVM itself still looks up the correct state during transaction execution. In this scenarios the worst that the RPC provider could do is a DOS by sending you a very large fake access list but since the RPC provider can already effectively DOS your application by not responding to requests this is likely acceptable.

Unfortunately, it will only work if the RPC provider returns the correct access list. We don't want to trust the RPC provider and so we can't really trust that they will provide a correct access list. They could for example provide you with an access list that will cause the eth_call result to be completely different, even though you are verifying the account and storage proofs of each account and slot there is no way to verify that you are looking up the correct pre-state before the transaction is executed.

You might be able to solve this problem by building up the access list yourself by executing the in memory EVM multiple times, each time collecting more of the access list keys and state until eventually executing the transaction against the full state which will give you the result for eth_call.

Here is the algorithm:

- Fetch code to be executed
- while the evm execution is not successful or the touched account,code,slots have changed since the last execution:
    - execute the code using in memory EVM
    - collect the touched account,code,slots from the evm state
    - fetch all touched account,code,slots concurrently and pass into a new evm state

The last execution will be successful and should be using the correct keys.

You can use the makeMultiKeys function in ledger.nim to collect the touched account keys and storage slots from the EVM state after executing the transaction. You might also be able to use the accessList functions for this.